Several leading technology organizations are investing in building technologies that sell “software-as-a-service”. Such services provide access to shared storage (e.g., database systems) and/or computing resources to clients or subscribers. Within multi-tier e-commerce systems, combinations of different types of resources may be allocated to subscribers and/or their applications, such as whole physical or virtual machines, CPUs, memory, network bandwidth, or I/O capacity.
One of the many benefits of using the software-as-a-service approach is that providing the desired levels of availability, data durability and scalability becomes the responsibility of the service operator. Clients of the services may simply decide what levels of availability, durability and performance they wish to pay for, and leave the implementation details to the services. The service operators may consequently establish numerous data centers, often geographically distributed across different cities, states, or even countries, and populate the data centers with computing, networking, and storage infrastructure based on expectations of client usage levels for the various services. The specific resources used for a given client may be selected from several different data centers, for example, to achieve desired levels of fault tolerance and data durability.
In at least some scenarios, internal services may be set up to manage some of the common components of functionality underlying various client-accessible services. For example, a large provider may implement a number of different database-related services, (e.g., relational database management services, object-oriented database services, NoSQL or non-relational databases, and the like, each targeted to different market segments) several of which may require state management for database objects such as tables or table partitions. A general-purpose state management service may be implemented for internal use within the provider's network, for use by each of the different database-related services. Such a state management service may also be used for managing states of resources used by other types of services, such as virtualized computing services, where for example health state transitions and overall responsiveness of various virtualization hosts and/or compute instances may need to be monitored.
The use of such internal state management services may reduce the need for different client-accessible services to re-implement similar pieces of underlying technology, thereby helping reduce costs for the service provider. However, at least under some circumstances, e.g., especially during periods of recovery from infrastructure outages, when a large number of state transitions may have to be handled within a short time period, it may be possible for the state management service itself to become overloaded, which can potentially lead to cascading problems for the client-accessible services.
While embodiments are described herein by way of example for several embodiments and illustrative drawings, those skilled in the art will recognize that embodiments are not limited to the embodiments or drawings described. It should be understood, that the drawings and detailed description thereto are not intended to limit embodiments to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope as defined by the appended claims. The headings used herein are for organizational purposes only and are not meant to be used to limit the scope of the description or the claims. As used throughout this application, the word “may” is used in a permissive sense (i.e., meaning having the potential to), rather than the mandatory sense (i.e., meaning must). Similarly, the words “include,” “including,” and “includes” mean including, but not limited to.